Cenários de BI
O propósito desta seção é dar idéias que permitam identificar alguns cenários de BI que sua organização pode estar enfrentando. Como resolver cada uma delas é assunto de outra seção (veja o link ao final de cada cenário).
Muitas informações são necessárias no dia-a-dia de uma empresa. Invariavelmente, todas elas dizem respeito à realizar alguma ação: um pedido chegou! O que produzir/embalar/entregar/consertar? Qual o limite de tempo para essas tarefas? Quando deve ser o pagamento? E quanto?
Se você faz o tipo caridoso, e acha que usar empresas como exemplo não é de bom tom, aqui está uma variação: uma ONG distribui computadores usados para pessoas de baixa renda. Muitas informações são necessárias no dia-a-dia e, invariavelmente, todas elas dizem respeito à realizar alguma ação: como descobrir quem vai comprar um micro novo para substituir um usado? Como descobrir quem precisa de um micro, mas não pode pagar, e não sermos enganados por "falsos pobres"? E os que já foram doados, estão sendo bem usados, ou foram revendidos, viraram video-games? A mão-de-obra voluntária está recebendo os micros e entregando-os reformatados no prazo?
Algumas situações são resolvidas por sistemas transacionais:
- Tratar pedidos.
- Rastrear pagamentos.
- Captar e Controlar doações.
- Controlar "linha de produção" de micro recondicionado.
E outras não:
- Os nossos clientes estão nos matando? Ou estamos captando e mantendo bons clientes?
- Qual é a lucratividade histórica da empresa e para onde ela está indo?
- Os nossos fornecedores estão nos matando?
Para a ONG:
- Quantas perdas estamos tendo, e onde?
- Nossa política de escolha de beneficiados está dando resultados, ou devemos revê-la?
- Quais voluntários são mais caros? Quais são mais eficientes? Quem podemos usar para treinar novos voluntários?
A situação que pode tirar proveito de uma solução de BI nem sempre é clara. A lucratividade é um parâmetro que pode ser extraído diariamente do, digamos, ERP (vamos chamá-los genericamente de OLTPs). Já os consolidados mensal e anual são mais complicados para se obter de um sistema transacional do que de um de BI, mas não impossíveis. Finalmente, uma previsão de lucratividade é inviável de ser programado em sistemas OLTP sem o auxílio de uma solução de BI para fornecer um modelo.
Cenário 1
Sua empresa tem vários sistemas transacionais, cada qual com sua quota de relatórios. Vira e mexe você, um gerente comercial, vendedor, analista de marketing ou diretor, precisa cruzar dados que existem em dois relatórios, e para isso precisa ligar para a TI. Ou, pior ainda, você é a TI e volta e meia tem alguma figura da empresa ligando para você, pedindo um novo relatório, e cada qual mais bizarro que o outro.
A origem dessa situação é clássica e bem conhecida: alguma ação precisa ser executada, seja para reverter um quadro desfavorável, seja para explorar novos territórios, implicando em tomar uma decisão que até então não era necessária. O encarregado dessa decisão, inicialmente, vai examinar as informações que dispõe e tentar chegar a alguma conclusão mais ou menos embasada. Se a insegurança diante das opções for grande o bastante, essa pessoa irá procurar mais informações, e é ai que o caldo entorna. Se a organização não possuir uma forma de se obter rapidamente informações precisas, o volume de trabalho de TI vai explodir: essa pessoa (ou, mais próximo da realidade, essas pessoas) vão montar acampamento na sala dos analistas, solicitando uma miríade de dados, relatórios, médias, desvios-padrão, e toda sorta de combinação desses.
O que as pessoas que precisam de informação estão fazendo é explorar seu ambiente em busca do conhecimento, da inteligência do negócio acumulada nos dados, nas pessoas, nas coisas, da mesma maneira que um varejista de bairro (aka dono de mercearia) lança mão de sua memória e conhecimento de mercado para decidir como formar estoque, fazer propaganda, dar descontos, etc.
Solução de BI recomendada: OLAP.
Cenário 2
Um dos
n estagiários do diretor vive na sua mesa pedindo algumas planilhas com dados, para ele poder fazer um gráfico que o big boss pediu (que depois vai te ligar, dizendo que não bate com o que ele calculou lá - vai saber porquê - mas não vai admitir que a culpa é do estagiário novato, que por acaso é sobrinho dele).
Diretores e presidentes não exploram dados para obter conhecimento. Eles são
o próprio conhecimento. Em tese, eles devem ter um conhecimento profundo do negócio em que estão, caso contrário sistema nenhum vai salvá-los de afundar a organização.
O que diretores e presidente procuram, via de regra, é saber se suas decisões estão sendo seguidas, e se os resultados consequência dessas decisões são os desejados. Traduzindo, eles precisam de visibilidade das operações da empresa. Empreendimentos desorganizados têm dificuldade de traduzir em números os projetos da diretoria/presidência, em decorrência da ordinária falta de integração das partes. Mesmo em empresas mais maduras, um certo nível de desintegração persiste. Na verdade, ainda que tudo fosse perfeitamente integrado, os sistemas voltados para o dia-a-dia não vão exibir dados de maneiras relevantes para estratégia e tática da empresa.
Atender esse tipo de necessidade é um jogo para times da primeira divisão; não há lugar para amadorismo. Uma famosa metodologia que atende essa necessidade é a BSC - Balanced Scorecard. Ele fornece uma visão da empresa através da medida de parâmetros previamente definidos. Essa metodologia (ou a qualquer outra que permita uma visão integrada da organização) precisa de uma solução tecnológica que execute as funções de captura de dados, tratamento, acúmulo e exibição.
Por sua vez, a tecnologia precisa permitir que os dados sejam seguidos até sua fonte e visualizados de várias formas. Menos incomum é a necessidade de cruzamento de dados. O tipo de tarefa que gera essa necessidade costuma ser repassado para os níveis intermediários - o pessoal do cenário 1. A tecnologia que melhor apoia metodologias como a BSC é o EIS,
Executive Information System (ou
Enterprise I.S.) porquê trazem interface mais uniforme, guiada (menos aberta que OLAP, p.e.) e que permite mais controle e riqueza sobre os elementos visuais.
Solução de BI recomendada: BSC sobre EIS. (E dispensar esses estagiários, ou mandá-los para outro departamento.)
Cenário 3
O supra-sumo do karma (senão você) surta: é só mostrar aquele relatório complicadíssimo que o gerente, após um rápido "scan" das colunas de dados, vira para você e diz "está ótimo, parabéns, mas agora separa por bairro e mostra um gráfico de barras do lado, aqui, ó" enquanto rabisca no canto daquela folha que tem mais horas de computador que o próprio gerente.
Por que é que o gerente surtado está atrás de tantos dados numa folha de papel? Porque esse é o único gerente que precisa de tanta coisa tão disparatada? Uma hora ele pede o histórico de vendas, depois pede para traçar isso num gráfico de barras, com a cotação do dólar em outro eixo; mais adiante muda de idéia e pede do euro, mas com uma linha extra sobre a temperatura média da cidade, com barras de erro e sem
outliers.
O que esse tipo mais raro de "trabalhador do conhecimento" está fazendo é tentar aplicar o que ele sabe para descobrir um fator oculto dentro dos dados da empresa. Esse não é um cenário comum, mas quando alguém assim é identificado o ideal é chamá-lo para uma conversa e perguntar se ele acha que precisa de um projeto de
Data Mining.
Um projeto de
Data Mining não pode ser tocado por uma única pessoa mas, por outro lado, não serve a um número grande de usuários (no máximo um departamento, como marketing, se não apenas alguns de seus membros). É um projeto, e não um sistema como os outros dois cenários, e é muito complexo.
Em geral, quando um projeto de
Data Mining é entendido como necessário, o cenário é invertido: a decisão vem pronta, ao invés de depender de uma sugestão da TI.
Solução de BI recomendada: Data Mining.
Cenário 4
Todos os dias os OLTPs da sua organização precisam parar por algum tempo para gerar um volume considerável de relatórios, para vários empregados, nos mais diversos níveis. Ao longo do dia esses relatórios vão ficando desatualizados e alguns precisam ser refeitos. Num cenário piorado, os relatórios são tirados on-line, afetando o desempenho dos sistemas em tempo real, pressionando a TI a aumentar o poder de processamento das máquinas, de aumentar a eficiência (seja trabalhando mais, contratando mais ou pagando a alguém para fazer). Com relativa frequência, novos relatórios precisam ser criados, por n motivos diferentes.
Essa situação difere do cenário 1 no fato de que os novos relatórios surgem em decorrência da evolução natural dos negócios (novos empregados, novas linhas de produtos, alterações na cobertura geográfica, mudanças de protocolos, estruturas internas e muitos outros fatores), e não da necessidade de um parte da empresa estudar seu dia-a-dia.
Tudo que a TI precisa oferecer é um ambiente com dados relativamente atuais, que disponibilize relatórios-padrão e permita criar outros. Essa é a solução primária de BI: consultas (
queries) e relatórios (
reporting), sobre um
data warehouse.
Solução de BI recomendada: Query & Reporting.
Conclusão
Haverá uma? Soluções de BI são únicas. Há uma taxonomia básica, mas o que vai atender sua organização e ajudá-la a resolver seu problemas é algo que vai nascer da complexidade natural do seu dia-a-dia. Talvez BSC com OLAP seja a ferramenta básica de todo gerente, Q&R seja uniforme para a empresa toda e a diretoria prefira se ocupar com projetos grandes como CRM, SCM ou
Financials.
Siga os links em cada cenário para aprender mais e entender melhor o que propor à sua organização. Se precisar de ajuda, procure os fóruns dessa wiki, que teremos prazer em trocar algumas idéias com você.